Thanks for your PR!
sshguard brings no security benefits with pubkey-based authorization, which is pre-enabled by configuration.nix.

To reduce logspam, users could also:

• bind sshd to another port
• bind sshd to a dedicated IPv6 address with a random interface identifier
• use port knocking

I don't think using sshguard is clearly the best solution here and I'd slightly vote against recommending it in configuration.nix.
@jonasnick, what do you think?

@erikarvstedt,

Thank you for your insightful feedback on the PR! I understand the concerns raised regarding the perceived limited benefits of sshguard when public key authorization is pre-enabled by configuration.nix, and I will add if this doesn't provide enough perceived value to be included I understand that and don't want to add too much bloat to the example file. So I understand that.

You're absolutely right; with public key authorization, the risks of brute-force and dictionary attacks are mitigated. However, I would like to highlight that the role of sshguard extends beyond protecting against these types of attacks. It serves as an additional layer of defense to help shore up potential unknown vulnerabilities in OpenSSH by blocking IPs exhibiting anomalous behavior, thus contributing to a defense in depth strategy.

Here’s a brief comparison with port knocking and dedicated binding that you highlighted, and I would argue that sshguard is the most user-friendly bang for the buck:

Port Knocking: While it offers stealth and selective opening of ports, it can be complex for typical users to set up and does not automatically block malicious IPs. I've used it in the past and for users like us it is definitely useful but the user experience for new users adds additional complexity and increases barrier to entry.

Dedicated Binding: It limits exposure by binding sshd to a dedicated IP or a different port, but like port knocking, it does not provide automatic blocking of malicious IPs and is more security through obscurity (which is fine to a degree, but port scanning all 65,535 is relatively trivial anymore using something like masscan or using something like shodan.

Both port knocking and dedicated binding are valuable for reducing exposure and allowing specific access, but they may lack in user-friendliness and do not address anomalous behavior indicative of exploitation attempts.

I proposed the implementation of sshguard as it provides a balanced, user-friendly approach to security, especially for typical users, and can work in conjunction with other security measures like port knocking and dedicated binding to provide a more comprehensive security solution for more experienced users. It adds a penalty to people attempting to attack systems at scale and removes them from the equation from public facing nodes.

Would love to hear your thoughts on this and whether you have any suggestions for improving the current PR to better align it with the project’s goals or I can close if this offers too little value in ya'll opinion.

Cheers,

Hi @ionisle, thanks for your PR and explanations!

We don't really have a policy for default options in configuration.nix. Right now, it mostly consists of nix-bitcoin specific options. I think a reasonable informal policy is to add "whatever we want to be enabled most of the time on our own nodes".

I'm not sure if that's the case for sshguard.

It serves as an additional layer of defense to help shore up potential unknown vulnerabilities in OpenSSH by blocking IPs exhibiting anomalous behavior,

Is that true? I can't find the claim on their website. If I understand correctly, it just reads log files to block connections. So even if the attack would produce a suspicious log line and the "attack scoring" by sshguard would be high enough to block the connection, it is likely to be too late - exploitation would have already happened.

So the main benefit for us appears to be preventing log spam at the cost of locking yourself out accidentally. Maybe changing the SSH port would be enough to reduce the spam.

@jonasnick,
Understood, all I will say is that it has served well in enterprises where I have deployed it on bastion hosts or other systems. I'm a traditional defense-in-depth guy. As for the additional layer of defense comment. Take the heartbleed vulerability from a few years ago (I realize ssh architecture is very different than tls and the threat model is different, but bear with me) It required a brute force attack to reveal sections of memory that eventually lead to a private key being exposed. As nix-bitcoin stores the public keys for authorization an attack like that won't appear here, but we don't currently have an idea of what kind of attacks may be available currently in SSH. This would simply be an additional layer that blocks potentially malicious traffic for a time to avoid attack vectors that an attacker could potentially exploit. It is something I run on my systems as nix makes it super easy to setup and the resource usage in negligible on most modern systems. It appears that it isn't everyone's cup of tea and i'm happy for you to close this if you don't think it provides any value as a potential add-on to the project.

Having said that, I'm here to contribute and help long-term, what are some of the pressing issues/things that need to get done?

Interesting to hear that you already have a significant amount of experience with this and

It required a brute force attack to reveal sections of memory that eventually lead to a private key being exposed

is a good point.

As for higher priority things to work on (imo):

• security-wise, Update to bitcoind 25.0 #611 is most important right now, but not really clear what to do
• Review Add mempool #505
• Signet support #532
• Add fedimint module

I'm closing this request, and will start finding what I can do on the list you mentioned.